home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / cbm / 2881 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: mail2news.demon.co.uk!insosf1.netins.net
  2. From: Alan Jones <alan.jones@qcs.org>
  3. Newsgroups: comp.sys.cbm
  4. Subject: Re: C= FP arithmetic
  5. Date: Sun, 18 Feb 1996 11:28:00 GMT
  6. Organization: Quad-cities Computer Society
  7. Message-ID: <96021817503147288@qcs.org>
  8. X-NNTP-Posting-Host: insosf1.netins.net
  9. X-Mail2News-Path: insosf1.netins.net
  10.  
  11.  
  12. ddeter T Karlsson <dat95pkn@idt.mdh.se> wrote:
  13. >>C=64+64*INT(.1+.9)
  14. >>will give C 64 for a C64 and 128 on a C128!
  15.  
  16. >I find this very interesting. Does anyone have an explanation for
  17.  this?
  18.  
  19. Craig Bruce replied:
  20.  
  21.  Floating-point arithmetic is a bit of a crap shoot anyway.  Maybe they
  22.  subtly changed the addition code between the two versions, or...
  23.  
  24.  I have some vague notions about the floating-point accumulators (FACs)
  25.  storing a number with slightly more precision than a floating-point
  26.  variable, so this may be what is happening.  If the number doesn't have
  27.  
  28.  to leave the FACs (which it doesn't in the above first example), then
  29.  there may be a slightly different answer from if it does.  Maybe the
  30.  C128 stores or doesn't store intermediate results from the FACs while
  31.  the C64 doesn't/does.
  32.  
  33.  
  34. I must disagree with Craig, but then I admit that I don't know enough
  35. about crap shooting. ;)
  36.  
  37. I too find this interesting.  I have not read much about our BASIC 7.0
  38. other than additional commands.  I don't know what the 128 does
  39. differently from the C64 here.  I am not surprised that INT(.9+.1) = 0
  40. on a C64.  I note that INT(9/10+1/10) produces the same poor result
  41. while avoiding the input conversion problem.  Actually I do all my
  42. numerical work using COMAL 2.0 on a C64 (or 128 in C64 mode at 2MHz).
  43. So far as I know, COMAL uses the same FP kernel FP arithmetic routines,
  44. although SQR (square root) was improved.
  45.  
  46. In COMAL at least, five byte floating point mumbers are fetched from
  47. memory and placed on the stack in a 6 byte form.  One byte is used to
  48. hold the sign and four bytes are used to hold the unsigned mantissa.
  49. In all cases proper rounding FP arithmetic is used, assuming you use
  50. the kernel FP routines.  I use a ML level 1 BLAS package with COMAL
  51. 2.0.  This calls the kernel math routines, but it is MUCH faster
  52. because it takes array indexing and other overhead out of the hands of
  53. the interpreter.  The interesting thing is that sometimes calculations
  54. made using the BLAS differ from the equivalent in-line code.  Because a
  55. partial sum can be kept on the stack, it sometimes behaves as a gaurd
  56. digit in the calculation.  When the results using the BLAS are
  57. different they can be considerred more accurate, even though the same
  58. FP arithmetic routines are used. :)
  59.  
  60. BTW, in COMAL 2.0 on a 128D in C64 mode, print int(.9+.1) is 1  :)
  61. If anyone is serious about doing "heavy math" on a C64 I strongly
  62. recommend the Comal programming language.
  63.  
  64. Someone recommeded using FP variables to hold integers.  Unfortunately,
  65. this only gives you 9 decimal digits before roundoff error creeps in.
  66. There are how many digits in the national debt?!!!!
  67.  
  68. There is nothing wrong with using BCD arithmetic.  Some of the most
  69. accurate numerical codes use BCD arithmetic.  One can find software for
  70. Interval Arithmetic and extremely high precision calculations (like
  71. calculating PI to bazillions of digits) using BCD arithmetic.
  72.  
  73. To be sure, FP arithmetic can produce some surprising results (at least
  74. for the unwary).  For example, it is an algebraic fact that a*b = b*a.
  75. But this in not always true of all FP arithmetics.
  76.  
  77. alan.jones@qcs.org
  78.  
  79. ___ QWKRR128 V4.32 [R]
  80.